Many operating systems divide memory into a kernel space and a user space. System calls in the operating system include parameters supporting the system call, and the parameters can be stored in either the user space or the kernel space. System call parameters that are too large to fit into parameter registers, such as string data, must be passed using a reference to the parameter data in user space. This data must be copied into kernel space for processing by kernel modules or the kernel itself. For example, in the implementation of the LINUX kernel module LOMAC, a system call parameter can be stored in the kernel space so that a user space program thread cannot alter the system call parameter. This kernel-space address can then be modified so that it can be used as a user-space address for the actual system call invocation.
However, in other operating systems, such as Solaris, AIX, and HP-UX, the system call parameters must be stored in user space. Storing the system call parameters in user space presents a disadvantage for kernel modules that intercept system calls wherein they are vulnerable to a time to check to time of use exploit (“TOCTOU”) that could lead to inconsistent evaluation of the system call parameters by the kernel module's system call intercept and the kernel's system call. A TOCTOU results from the time gap between issuance of the system call, and the kernel accessing the parameters. This time gap exposes the parameters to alteration from a multi-threaded application.
For example, a multithreaded application intent on exploiting TOCTOU, repeatedly calls open( ) with a file path string, while a second thread continually changes the file path string from a path that the process has permission to access to a path that the process is not authorized to access. For example, a process is authorized to access /etc/a but not /etc/b. The process issues the system call to /etc/a and alters the path to etc/b. In a successful TOCTOU, the parameters eventually cross during the time gap, and the process will undesirably be granted access to /etc/b.
Potential solutions to prevent a TOCTOU have required a significant amount of platform specific code. Some solutions have even required kernel release specific code. Both solutions undesirably can result in significant repeated labor. Other solutions rely on mechanisms that may not be implemented across all platforms. Another solution relies on extending the heap of the process to acquire a page of memory such that the process does not have a reference to the memory. However, such a ‘heap’ solution is susceptible to a brute force memory exploration in the event that the TOCTOU application is aware or suspects such a defensive tactic.
It is therefore a challenge to develop a method to prevent TOCTOU exploits and to overcome these, and other, disadvantages.